Event-driven communications offer a number of advantages, for example, providing essentially immediate data when an event creating the data occurs. Therefore, event-driven communications are especially useful, for example, where timely information dissemination is required, where notice of changes or status must constantly occur, where real time information monitoring and real time decisions are required.
Event-driven communications reduce traffic by publication of data to subscribers which requires no explicit action by a subscriber in order to receive the data. Moreover, a publication of data to subscribers requires only a single publication from a publishing source to a channel no matter how many subscribers are to receive the data.
Known event-driven communications systems are implemented utilizing various data access protocols which exist to facilitate the transfer of data between disparate systems in order to utilize object-based software which make it easy for a user to acquire data at a time when it is most useful. The use of these protocols allows the burden of overcoming interfacing problems and establishing communication channels. However, such a system requires that a publisher and a subscriber agree on a format for the data being exchanged. As a result complex formatting of input files and streams is required. In such systems the format is hardcoded in parsers which requires the parsers to be updated for any changes in input sources. Furthermore, data analysers, filters, correlators, forwarders and persisters must be separately updated whenever an event is updated. This makes such systems inflexible, making it difficult to integrate new and unforeseen event processing technologies or event publishing mechanisms into these current systems.
Event-based mechanisms are also being increasingly used in gathering network and terminal metrics to provide more timely and granular information to operators of the network for monitoring performance, quality of service and experience over the network. In addition, file-based collection mechanisms are being replaced by event streaming mechanisms.
Traditionally, metrics are reported by use of counters. A vast number of counters are available, aggregating metrics such as packet loss, delay, and jitter as well as on network events such as equipment failures and overloads. Counters are also used to report on logical entities such as Virtual Local Area Networks (VLANs) and MultiProtocol Label Switching (MPLS) tunnels. Simple Network Management Protocol (SNMP) MIBs described in K. McCloghrie and M. Rose, “RFC1213: Management Information Base for Network Management of TCP/IP-Based lnternets: MIB-II,” RFC Editor United States, 1991 and the 3GPP PM Integration Reference Point (IRP) described in “3GPP TS 52.404: Telecommunication Management; Performance Management (PM); Performance Measurements—GSM,” 3GPP TS 52.402, March 2011 are just two of very many standards that specify counters and counter handling.
In telecommunication networks, counter collection is usually implemented using a batch mechanism. Counters for a given reporting period (a reporting period of 15 minutes is typical, but reporting periods of 5 minutes or even shorter are sometimes used for critical counter data) are stored into files on network elements. A management system regularly collects the counter files from the network elements. This mechanism is explained in more detail in A. Clemm, Network Management Fundamentals. Cisco Press, 2006, pp155-157. Batch collection of counters is a very efficient way of transmitting counter information because all the information for a reporting period is sent in one communication session. If counter files are compressed, even higher efficiency can be achieved. The drawbacks of batch collection are that there is an inherent delay of at least one reporting period before counter data can be collected and processed. Another drawback is that the files must be temporarily stored on network elements prior to collection.
Counter based metric reporting is a very efficient approach to network monitoring, network elements calculates counters from raw information, with just the counter information being stored and reported. The main disadvantage of counter based metric reporting is that raw information on the cause of incidents is not available for analysis.
The use of common access and core networks for all telecommunication services means that it is difficult to infer a network-wide view of how well those services are being delivered from counters alone.
In order to analyse how well end user services being delivered by today's networks, for example, “Keeping the Customer Service Experience Promise” White Paper, January 2011 http://www.ericsson.com/res/docs/whitepapers/wp_service_assurance.pdf Document No. 284-23-3150requires access to rich source data. Event-based metric collection, where network elements report metrics on significant events in bearer and control sessions, are increasingly being used to provide the rich source of data.
Nodes of existing networks already support event based reporting Node B (a radio base station in UMTS) in LTE (eNodeB) nodes, Serving General Support Node (SGSN) nodes, Gateway General packet radio Support Node (GGSN) nodes, and Mobility Management Entity (MME) nodes report radio and core network events. Probes can be used to report events on signalling and bearer links at Internet Protocol (IP), Transmission Control Protocol (TCP), and application protocol level. Quality of Service (QoS) and Quality of Experience (QoE) reports can be received from terminals running Real-Time Protocol (RTP) sessions using Real-Time Control Protocol (RTCP) described, for example, in H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, “RTP: A Transport Protocol for Real-Time Applications,” RFC 3550, July 2003 as well as from 3GPP Packet-switched Streaming Service (PSS) described, for example, in “Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs,” 3GPP TS 26.234, December 2010, Multimedia Broadcast/Multicast Service (MBMS) described, for example, in “Multimedia Broadcast/Multicast Service (MBMS); Protocols and Codecs,” 3GPP TS 26.346, October 2010 and Multimedia telephony (MMTel) described, for example, in “IP Multimedia Subsystem (IMS); Multimedia Telephony; Media Handling and Interaction,” 3GPP TS 26.114, December 2010.
Event-based metrics are usually streamed from network elements, probes, or terminals to management systems. Internet Protocol Flow Information Export (IPFIX) described, for example, in E. B. Claise, “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information,” RFC 5101, 2008 is used to stream reports of events on IP flows from network elements and probes. Ericsson nodes support streaming of events to management systems and also support file based batch event collection as aforementioned.